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ABSTRACT 

Content-Centric Networking (CCN) is an emerging network 
architecture designed to overcome limitations of the current 
IP-based Internet. One of the fundamental tenets of CCN 
is that data, or content, is a named and addressable entity 
in the network. Consumers request content by issuing in¬ 
terest messages with the desired content name. These in¬ 
terests are forwarded by routers to producers, and the re¬ 
sulting content object is returned and optionally cached at 
each router along the path. In-network caching makes it dif¬ 
ficult to enforce access control policies on sensitive content 
outside of the producer since routers only use interest in¬ 
formation for forwarding decisions. To that end, we pro¬ 
pose an Interest-Based Access Control (IBAC) scheme that 
enables access control enforcement using only information 
contained in interest messages, i.e., by making sensitive con¬ 
tent names unpredictable to unauthorized parties. Our IBAC 
scheme supports both hash- and encryption-based name ob¬ 
fuscation. We address the problem of interest replay attacks 
by formulating a mutual trust framework between producers 
and consumers that enables routers to perform authorization 
checks when satisfying interests from their cache. We assess 
the computational, storage, and bandwidth overhead of each 
IBAC variant. Our design is flexible and allows producers to 
arbitrarily specify and enforce any type of access control on 
content, without having to deal with the problems of content 
encryption and key distribution. This is the hrst comprehen¬ 
sive design for CCN access control using only information 
contained in interest messages. 


1. INTRODUCTION 

The purpose of the original Internet in the 1970s was 
to provide end-to-end communication for a few thou¬ 
sand users to access scarce and expensive resources via 
terminals. Since then the number of Internet users has 
grown exponentially, reaching more than 3 billion, with 
each using a wide variety of applications from the dy¬ 
namic web to content distribution. This shift of usage 
exposed certain limitations of the IP-based Internet de¬ 
sign and motivated exploration of new architectures. 

Content-Centric Networking (CCN) is an approach 
to inter-networking e xem plified by two well-known re¬ 
search efforts: CCNx 18 and Named-Data Networking 


(NDN) 1^. The mam goal of CCN is to develop the 
next-generation Internet architecture with an emphasis 


on efficient content distribution, security, and privacy. 
Unlike current IP-based networking where data is re¬ 
quested by addressing the machine where it is hosted, 
each CCN content is assigned a unique name. Users 
(referred to as consumers) request content objects by 
issuing an interest for a given name. This interest can 
then be satisfied or served from any entity (i.e., pro¬ 
ducer or router) as long as the replied content’s name 
matches that of the interest. 

To facilitate efficient content distribution, a CCN router 
maintains a cache. This enables routers to satisfy in¬ 
terests, which reduces end-to-end latency and decreases 
bandwidth utilization when requesting popular content. 
Since interest messages may be satisfied by any cached 
version of the content, interest messages may not, and 
need not, reach the producer. Therefore, enforcing con¬ 
tent access control within the network is a challenge. 
Furthermore, even if all interests are forwarded to pro¬ 
ducers, the latter might not be able to enforce access 
control since interest messages, by design, do not carry 
any form of consumer identification or authentication 
information. 

In this paper, we propose an access control scheme 
based on interests - Interest-Based Access Control (IBAC). 
The intuition is that if consumers are not allowed ac¬ 
cess to certain content, they should not be able to gen¬ 
erate the corresponding interests, i.e., they should not 
be able to learn the content’s name. IBAC may also be 
used with content encryption to conceal both the name 
and the payload of the content object. However, using 
IBAC in isolation is advantageous in scenarios where 
content object payloads may need to be modified by 
an intermediate service, e.g., a media encoding applica¬ 
tion or proxy. In this case, content encryption prevents 
such modifications by services or applications besides 
the producer. Moreover, although IBAC involves the 
network layer, we believe that this is necessary to al¬ 
low routers (with caches) to enforce access control. To 
be more specific, we claim that any entity which serves 
eontent should also be able to authorize interests for said 
content. 

The main contributions of this paper are: 

• Architectural modifications to support IBAC with¬ 
out diminishing caching benefits. 

• A mutual trust scheme wherein routers can verify 
whether consumers are authorized to access cached 
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content. 

• A security analysis of the proposed IBAC scheme. 

• Evaluation of router performance overhead when 
serving content via IBAC compared to publicly ac¬ 
cessible content. 

The rest of this paper is organized as follows. Section 
[^presents an overview of CCN architectures in the con¬ 
text of CCNx. Section 1^ then provides an overview of 
access control techniques for CCN, including encryption- 
and interest-based access control. Section presents 
the relevant security definitions and adversarial models 
used to assess the IBAC scheme discussed at length in 
Section We discuss the IBAC security consideration 
in Section]^ We then analyze the overhead incurred by 
IBAC in Section [ 7 ] and conclude in Section |8l 


2. CCN OVERVIEW 


Content Centric Networking (CCN) is one of the main 
Information-Centric Networking (ICN) architectures. Re¬ 
lated architectures, such as Named Data Networking 
(NDN) I^, are similar, albeit with some small protocol 
and packet format differences. This section overviews 
ICNs in the context of the CCN protocol and CCNx 
reference implementation. Given familiarity with ei¬ 
ther CCN or NDN, it can be skipped without loss of 
continuity. 

In contrast to TCP/IP, which focuses on end-points 
of communication and their names and addresses, ICN 
architectures such as CCN focus on content by 

making it named, addressable, and routable within the 
network. A content name is a URI-like name com¬ 
posed of one or more variable-length name components, 
each separated by a / character. To obtain content, a 
user (consumer) issues a request, called an interest mes¬ 
sage, with the name of the desired content. This interest 
will be satisfied by either (1) a router cache or (2) the 
content producer. A content object message is returned 
to the consumer upon satisfaction of the interest. More¬ 
over, name matching in CCN is exact, e.g., an interest 
for lei:/facebook/Alice/profile.html can only be 
satisfied by a content object named lei:/facebook/ 
Aliee/profile .htmlQ 

Aside from the content name, CCN interest messages 
may include the following fields: 

• Payload - enables consumers to push data to pro¬ 
ducers along with the request]^ 

• KeylD - an optional hash digest of the public key 
used to verify the desired content’s digital signa¬ 
ture. If this field exists, the network guarantees 
that only content objects which can be verified 
with the specified key will be returned in response 
to an interest. 

• ContentObjectHash - an optional hash value of 
the content being requested. If this field exists. 


^Name matching is not exact in NDN 
^Currently, NDN interest 


messages do not provide an 
arbitrary-length payload and therefore cannot support the 
proposed IBAC scheme. However, if in the future the NDN 
interest format is modified to include a field similar to the 
CCNx payload, our IBAC scheme will become applicable. 


the network guarantees the delivery of the exact 
content that consumer requests. 

CCN content objects include several fields. In this work, 
we are only interested in the following three: 

• Ncune - a URI-like name formatted as a sequence 
of /-separated name components. 

• Validation - a composite of validation algorithm 
information (e.g., the signature algorithm used, its 
parameters, and a link to the public verification 
key), and validation payload (e.g., the signature). 
We use the term “signature” to refer to this field. 

• ExpiryTime ~ an optional, producer-recommended 
time for the content objects to be cached. 

There are three basic types of entities in CCN that are 
responsible for transferring interest and content object 
messages]^ 

• Consumer - an entity that issues an interest for 
content. 

• Producer - an entity that produces and publishes 
content. 

• Router - an entity that routes interest packets and 
forwards corresponding content packets. 

Each CCN entity must maintain the following two com¬ 
ponents: 

• Forwarding Interest Base (FIB) - a table of name 
prefixes and corresponding outgoing interfaces. The 
FIB is used to route interests based on longest- 
prefix-matches of their names. 

• Pending Interest Table (PIT) - a table of outstand¬ 
ing (pending) interests and a set of corresponding 
incoming interfaces. 

An entity may store an optional Content Store (CS), 
which is a buffer used for content caching and retrieval. 
Again, the timeout of cached content is specified in the 
ExpiryTime field of the content header. From here on, 
we use the terms CS and cache interchangeably. 

Router entities use the FIB to forward interests from 
consumers to producers, and then later use the PIT to 
forward content object messages along the reverse path 
to the consumer. More specifically, upon receiving an 
interest, a router R first checks its cache to see if it can 
satisfy this interest locally. Producer-originated digi¬ 
tal signatures allow consumers to authenticate received 
content, regardless of the entity that actually served 
the content. Moreover, the Interest-Key Binding rule 
(IKB) i enables routers to efficiently verify received 
content signatures before caching, in order to avoid con¬ 
tent poisoning attacks [^. Essentially, consumers and 
producers provide routers with the required trust con¬ 
text to enable efficient signature verification. 

When a router R receives an interest for name N 
that is not cached and there are no pending interests 
for the same name in its PIT, R forwards the interest 
to the next hop according to its FIB. For each forwarded 
interest, R stores some amount of state information, in¬ 
cluding the name of the interest and the interface from 
which it arrived, so that content may be sent back to 
the consumer. If an interest for N arrives while there is 

^A physical entity, or host, can be both a consumer and 
producer of content. 
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already an entry for the same content name in the PIT, 
R only needs to update the arriving interface. When 
content is returned, R forwards it to all of the corre¬ 
sponding incoming interfaces, and the PIT entry is re¬ 
moved. If a router receives a content object without a 
matching PIT entry, the message is deemed unsolicited 
and subsequently discarded. 


3. ACCESS CONTROL OVERVIEW 

One key feature of CCN is that content is decoupled 
from its source; there is no notion of a secure channel be¬ 
tween a consumer and producer. Consequently, ensur¬ 
ing that only authorized entities have access to content 
is a fundamental problem. In this section, we explore 
complementary approaches to access control: (1) con¬ 
tent encryption and (2) interest name obfuscation and 
authorization. 


3.1 Encryption-Based Access Control 

The most intuitive solution to the access control prob¬ 
lem is via encrypted content which can only be de¬ 
crypted by authorized consumers possessing the appro¬ 
priate decryption key(s). This enables content objects 
to be disseminated throughout the network since they 
cannot be decrypted by adversaries without the appro¬ 
priate decryption key(s). 

Many variati ons of this approac h h ave been proposed 
Kurihara et al. 
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16 generalized these 


specialized approaches in a framework called CCN-AC, 
an encryption-based access control framework to im¬ 
plement, speciW and enforce access policies. It uses 
CCN manifest^ to encode access control specification 
information for a particular set of content objects. Con¬ 
sumers use information in the manifest to (1) request 
appropriate decryption keys and (2) use them to de¬ 
crypt the content object(s) in question. 

Outside of ICN, there have been many proposed ac¬ 
cess control frameworks based on encryption. Recently, 
access control in shared cloud storage or social network 
services, e.g., Google Drive, Dropbox, and Facebook, 
generated a great dea l of attention from the research 
21 For instance, Kamara et al. 


com munity 
[T^ model© 
ter 


encryption- based access control framework 
or cloud storage. Microsoft PlayReady is another 
popular access control framework for encrypted content 
dissemination over the Internet. 

Despite its widespread use, encryption-based access 
control causes potentially prohibitive overhead for both 
producers and consumers. It most cases where hybrid 
encryption is used, it also requires keys to be distributed 
alongside each content object, which introduces another 
consumer-to-producer message exchange. Also, encryption- 
based access control does not provide flexibility if con¬ 
tent objects need to be modified by an intermediate 
service, e.g., a media encoding or enhancement applica¬ 
tion. Content encryption prevents such post-publication 


^Manifests are special types of content that are used to pro¬ 
vide structure and additional information to otherwise flat 


and simple content objects 118 ] 


modifications without revealing the secret decryption 
key(s) to such services. 

3.2 Interest-Based Access Control 

Interest-based access control (IBAC) is an alternative 
technique, though not mutually exclusive with content 
encryption, for implementing access control in CCN. It 
is based on interest name obfuscation and authorized 
diselosure. Name obfuscation hides the targe t of an in¬ 
terest from eavesdroppers. As mentioned in 11 , name 


obfuscation has no impact on the network since routers 
use only the binary representation of a name when in¬ 
dexing into PIT, CS, and FIB. As long as producers 
generate content objects with matching names, the net¬ 
work can seamlessly route interests and content objects 
with obfuscated names. However, interests with obfus¬ 
cated names must contain routable prefixes so that they 
can be forwarded from consumers to the producers. In 
other words, only a subset of name components (e.g., 
suffix of the name) is obfuscated. 

Another goal of name obfuscation is to prevent unau¬ 
thorized users from creating interests for proteeted con¬ 
tent. In other words, if a particular consumer Cr is not 
permitted to access content with name N, Cr should 
not be able to generate N' = f{N), where /(•) is some 
obfuscation function that maps N to an obfuscated name 
N'. For routing purposes, only the suffix of the name 
is obfuscated; there must exist a cleartext prefix that 
is used to route the interest with a partially obfuscated 
name to the intended producer. Possible obfuscation 
functions include keyed cryptographic hash functions 
and encryption algorithms. We explore both possibili¬ 
ties in this paper. 

Authorized disclosure is the second element of IBAC. 
This property implies that any entity serving content 
must authorize any interest for said content before it 
is served. In this context, authorization is necessarily 
coupled with authentication so that the entity serving 
the content can determine the identify of the request¬ 
ing consumer. Therefore, consumers must provide suf¬ 
ficient authentication information, e.g., via an interest 
signature. Thus, to implement authorized disclosure (in 
the presence of router caches), any entity serving con¬ 
tent must (a) possess the information necessary to per¬ 
form authentication and authorization checks and (b) 
actually verify the provided authentication information. 
This issue is discussed at length in Section |6.2| It is 
worth mentioning that disabling content caching defers 
authorized disclosure checks to producers. In this case, 
all interests will be forwarded to producers that posses 
the information needed to perform these checks. How¬ 
ever, by itself, prohibiting content from being cached is 
not a form of access control and reduces the effective¬ 
ness of content retrieval. 

Fotiou et. al. proposed an access control mech¬ 
anism similar to IHAC for non-ICN architectures, and 
conjectured that it should be applicable to ICNs. In [^, 
access control computation and overhead are delegated 
to a separate, non-cache entity. This entity, known 
as the access control provider, maintains access control 
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policies given by a specific producer. Each content ob¬ 
ject has a pointer to a function that determines whether 
or not to serve the content to the requesting consumer, 
and the access control provider is responsible for eval¬ 
uating this function. Content objects are stored at re¬ 
laying parties, which are oblivious to the specific ac¬ 
cess control policy protecting the content objects. Sim¬ 
ilarly, the access control provider has no knowledge of 
the consumer requesting the content (for user privacy 
purposes), and just evaluates whether the relaying party 
should forward the content object. The cache, in this 
scenario, is not responsible for the extra computational 
overhead. This approach is different from our work in 
that we (1) maintain the association between content 
and authorization, and (2) provide routers with an effi¬ 
cient authorization verification method, thus eliminat¬ 
ing the need for an external access control provider. 

4. SECURITY MODEL 

Let U(iV) denote the set of authorized consumers for 
a content object with name N generated and controlled 
by a producer P, and let t]{N) be its complement, i.e., 
the set of all unauthorized consumers. Let Path(Cr, P) 
be the set of all routers on the path between the con¬ 
sumer Cr G U(JV) and P. We assume the existence 
of an adversary Adv who can deploy and compromise 
unauthorized consumer any any router P ^ pQ To 
keep this model realistic, we assume that the time to 
mount such an attack is non-negligible, i.e., longer than 
the average RTT for a single interest-content exchange. 
Table [T] summarizes the notation used in the rest of this 
paper. 

Formally, we define Adv as a 3-tuple: (PAdv\{-f’}, CAdv\ 
U(A^),PAdv \ Path(Cr,P)) where the components de¬ 
note the set of compromised producers, consumers, and 
routers, respectively. If Adv controls a producer or a 
consumer then it is assumed to have complete and adap¬ 
tive control over how they behave in an application ses¬ 
sion. Moreover, Adv can control all of the timing, for¬ 
mat, and actual information of each content through 
compromised nodes and links. 

Let Guess denote the event where Adv correctly re¬ 
covers the obfuscated form of a content name. Let 
Bypass denote the event where Adv successfully by¬ 
passes the authorization check for a protected content 
object. We define the security of an IB AC scheme with 
respect to these two events as follows. 

Definition 1. An IB AC scheme is secure, but subject 
to replay attacks, if Pr[Guess] < e{K) for any negligible 
function e and a security parameter k. 

Definition 2. An IBAC scheme is secure in the pres¬ 
ence of replay attacks, if Pr[Guess -|- Bypass] < e{K) for 
any negligible function e and a security parameter k. 

Replay attacks are artifacts of the environment where 
CCN access control scheme is deployed. In other words, 

®Any one of these actions can be performed adaptively, i.e., 
in response to status updates or based on observations. 


Table 1: Relevant notation. 


Notation 

Description 


Adversary 

Cr 

Consumer 

P 

Producer 

prefix 

Producer prefix 

N 

Content name in cleartext 

N' 

Obfuscated content name 

W] 

Interest with name N 

CO 

Content object 

COIN] 

Content object with name N 

IDTA) 

Key identifier function 

m 

Obfuscation function 

enc(-,-),dec(-,-) 

Symmetric-key encryption and 
decryption function 

Enc(-, ■), Dec(-, ■) 

Public-key encryption and 
decryption function 

HD 

Cryptographic hash function 

WN) 

Set of authorized consumers 


Access control group i 

kc, 

Obfuscation key of group dji 


Public and private signing key pair 
associated with group Gj 

K. 

Global security parameter 

c 

Set of all content objects 

r, t 

nonce and timestamp 

B 

Nonce hash table 


in networks where links are insecure, passive eavesdrop¬ 
pers can observe previously issued interests and replay 
them for protected content. Consequently, these attacks 
are considered orthogonal to the security of the underly¬ 
ing obfuscation scheme used for access control enforce¬ 
ment. The authorized disclosure element of IBAC is 
intended to prevent such replay attacks. 

To justify our adversarial limitation to off-path routers, 
consider the following scenario. If Adv can compromise 
a router R G Path(C'r, P), then Adv is able to observe 
all content that flows along this path. Therefore, we 
claim that on-path adversaries motivate access control 
schemes based on content encryption; IBAC will not 
suffice. Moreover, we exclude adversaries capable of 
capturing interests and replaying them in other parts 
of the network - see Section IfiTl for details. 

5. IBAC BY NAME OBFUSCATION 

Recall that the intuition behind IBAC is that if con¬ 
sumers are not allowed to access certain content, they 
should not be able to issue a “correct” interest for it. 
Specifically, only a consumer Cr G U(N) should be able 
to derive the obfuscated name JV' of an interest request¬ 
ing content with name IV provided by producer P. In 
this section, we discuss two types of name obfuscation 
functions: (1) encryption functions and (2) hash func¬ 
tions. 

5.1 Encryption-Based Name Obfuscation 

Let Enc(fc,iV) be a deterministic encryption function 
which takes as input a key k G {0,1}'' and an arbitrary 
long non-empty binary name string N, and generates 
an encrypted name N'. Let Dec{k,N') be the respec¬ 
tive decryption function. With encryption, the goal is 
for authorized clients to encrypt components of a name 
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so that the producer can perforin decryption to identify 
and return the appropriate content object]^ Obfusca¬ 
tion is based on knowledge of the encryption key and the 
content name under IBAC protection. In other words, 
even if an adversary knows the name N, it cannot gen¬ 
erate N' since it does not possess the appropriate key. 

To illustrate how encryption-based obfuscation would 
work, assume first that Cr uses k to generate N' as 
N' = Er\c{k,N). P then recovers N as N = Dec{k,N') 
to identify the content object in question and returns it 
with the matching name N' (not N). We prove the se¬ 
curity of this obfuscation variant of IBAC (i.e., without 
authorized disclosure) in Appendix [A| 

Supporting Multiple Access Groups: Thus far, we 
assumed that name encryption (obfuscation) keys are 
known to all authorized consumers in U(A). However, 
this might not be the case in practice. P might provide 
content under IBAC to several access groups each with 
different privileges]^ Specifically, consumers in groups 
<Gi(A) C U(7V), for i = I, 2,..., might be allowed ac¬ 
cess to different resources. Therefore, several obfusca¬ 
tion keys, one for each group, should be utilized. For 
notation simplicity, we refer to Gi{N) as Gi. Note that 
in an extreme scenario, each group would only contain 
a single consumer, i.e., each individual consumer has a 
unique key used to access the content in question. 

To decrypt the obfuscated name N', P must identify 
the obfuscation key used to generate N'. This can be 
achieved if such consumers specify an identifier for the 
key used in the interest. Such an identifier could simply 
be the digest of the obfuscation key IDg^ = H(/cgJ, 
where /cg; is Gi’s encryption key. IDg^ can be included 
in the interest Payload field. Since matching in CCN 
is exact, IDg^ cannot be included in interests name. 

Recall that CCN interest messages, by design, do not 
carry any source information, which provides some de¬ 
gree of anonymity. However, including IDg^ enables in¬ 
terest linkability by eavesdroppers (malicious or not). 
In other words, IDg^ can reveal the access group iden¬ 
tities to which consumers belong, but not the identities 
of the consumers themselves. If this linkability is an is¬ 
sue for applications, H(fcGi) can be encrypted using P’s 
public key pk^ in the form IDg; = Enc(pfc^, H(fcGi))j3 
Note that for two identifier values of the same group, 
i.e., with the same k, to be indistinguishable, Enc(-, •) 
must be secure against chosen plaintext attacks [Ti) . 

5.2 Hash-Based Name Obfuscation 

Let H(A:, A) be a keyed cryptographic hash function. 
The obfuscated name N' can be generated as N' = 
H(fc, N) for some key k G {0,1}''. Since hash functions 

® Recall that a cleartext name prefix is needed to route the 
interest to the intended producer. 

^We assume that each content object is only accessible by 
a single access group. However, this assumption will be 
relaxed later in the paper. 

®Since a consumer cannot be expected to know the router 
from which content will be served, it is not plausible for 
them to encrypt these IDs with the public key of a (set of) 
router(s). 


are one-way, producers must maintain a hash table that 
maps obfuscated names to the original content name, 
i.e., M : N' = H{k, N) —>■ N for all deployed keys|^ The 
size of this hash table is C>(|IK| x |C|), where K is the set 
of all keys and C is set of all content objects generated 
or published by P under IBAC protection. This ap¬ 
proach provides the same benefits of encryption-based 
name obfuscation, however, it incurs additional com¬ 
putation and storage overhead at the producer. Thus, 
while keyed hash functions are viable for name obfus¬ 
cation, deterministic encryption is a much better ap¬ 
proach. 

6. SECURITY CONSIDERATIONS 

In this section we discuss the security of IBAC with 
respect to the adversary model described in Section]^ 

6.1 Replay Attacks 

Regardless of the obfuscation function used, both pre¬ 
viously described IBAC schemes are susceptible to re¬ 
play attacks. This is because both obfuscation functions 
are deterministic. Therefore, an eavesdropper Adv S 
U(A) could issue an interest with a captured N' and 
receive the corresponding content under IBAC protec¬ 
tion from either the producer or a router cache. In 
other words, the same “feature” that makes it possi¬ 
ble for authorized consumers to fetch IBAC-protected 
content from router caches also makes it susceptible to 
replay attacks. 

Such replay attacks are problematic in many access 
control systems. Standard countermeasures include the 
use of random, per-message nonces or timestamps. Nonces 
help ensure that each message is unique, whereas times¬ 
tamps protect against interests being replayed at later 
points in time. Thus, to mitigate replay attacks, we use 
both nonces and timestamps. In particular, each con¬ 
sumer Cr G U(A) must issue an interest with (1) name 
N', (2) a randomly generated nonce r, and (3) a fresh 
timestamp t. The reason why we use both nonces and 
timestamps is to allow for loosely synchronized clocks 
and unpredicted network latencies. Note that if (I) 
clocks of consumers, producers, and involved routers 
in IBAC can be perfectly synchronized, and (2) net¬ 
work latencies can be accurately predicted, only times¬ 
tamps are sufficient for replay detection. Moreover, 
since nonces and timestamps serve a purpose which is 
orthogonal to content identification and message rout¬ 
ing, they are included in the interest payload. 

Consumer nonces are random K-bit values. If a router 
receives a duplicate nonce, it can safely assume that the 
corresponding interest is replayed and drop it. Let w 
be a time window associated with authorized content 
To determine if a duplicate nonce was received, produc¬ 
ers (or caches) must maintain a collection of nonces for 

® Producers do not have to keep hash tables for all possible 
keys of size n, only tables of keys used by producers and 
issued to access groups. 

Determining the proper value of w is outside the scope of 
this paper. However, a logical approach is for routers to use 
the lifetime of authorized content as w. 


5 




each such content. In other words, this historical infor¬ 
mation is necessary to prevent replay attacks. Times¬ 
tamps themselves are not stored, they are only used 
to determine if the received interest is issued within 
the acceptable time window w. Once this time win¬ 
dow elapses, all of the stored nonces are erased and the 
content is subsequently flushed from the cache. 

Although using nonces and timestamps allows detec¬ 
tion of replayed interests, Adv capturing interests can 
still use their obfuscated names N' to fabricate another 
interest with legitimate r and t values. Therefore, we 
also stipulate that r and t should be authenticated via 
a digital signature; their signature tr is also included in 
the interest Payload field. In order to bind r and t to 
their corresponding interest, N' is also included in the 
signature computation, cr generation and verification 
should be performed using the public and private key 
pairs associated with each access group Gi. 

After adding nonces, timestamps, and a signature, 
interest Payload fields take the following form: 

Payload = (^1 Dg,, r,t,cr = Sign^^s (IV'||IDGj|r||t)) 

where IDg^ is the identify of group (G^, and sfcg. is a 
signing key distributed to all consumers in G^. To ver¬ 
ify cr, the matching public key pk^. must be obtained. 
For the remainder of this paper, we use the term autho¬ 
rization information to refer to all information included 
in interest Payload fields for the purpose of supporting 
IB AC. 

One alternative to digital signatures would be to use 
a keyed hash or a Message Authentication Code func¬ 
tion such as (HMAC) f^. In this case, consumers and 
routers would need to share the key used in the HMAC 
computation. This means that either consumers or pro¬ 
ducers need to distribute HMAC keys to all involved 
routers. This, however, is problematic for two main 
reasons: (1) compromising routers leads to HMAC keys 
leakage, and, more importantly, (2) if consumers pro¬ 
vide routers with these keys, the former need to know 
the set of routers that their interests traverse before 
issuing them. Furthermore, since HMAC keys should 
only be shared among involved all entities, i.e., Cr and 
all routers on Path(C'r, P), they must be distributed se¬ 
curely. Regardless of the distribution method used, this 
incurs extra overhead and complexity compared to sim¬ 
ply including, in cleartext, signature verification (pub¬ 
lic) keys in content objects. 

Finally, consider the following scenario where two 
routers i?i and R 2 cache content object CO[N'] which is 
under IBAC protection. Assume that consumer Cr re¬ 
quests CO[N'] by sending an interest I[N'] with valid 
authorization information that includes r and t. As¬ 
sume that I[N'] is satisfied from Rfs cache. At the 
same time, Adv, an eavesdropper between Cr and i?i, 
records I[N']. In this case, Adv can replay I[N'] to 
i ?2 and receive CO[N'] from the cache since routers do 
not synchronize stored nonces. Therefore, there is no 
way for R 2 to know that r and t were already used at 
i?i. One way of solving this problem is to have routers 


share used nonces lists for each content under IBAC 
they serve from cache. For this method to be effective, 
such nonces lists need to be securely shared with every 
single router in the network. This might not be fea¬ 
sible in large networks such as the Internet. Another 
approach is to have more accurate synchronized clocks 
allowing a smaller time window for the aforementioned 
attack to be carried. 

6.2 Authorized Content-Key Binding Rule 

Although the aforementioned method for generating 
authorization information mitigates replay attacks, it 
also raises several questions. Firstly, how does a router 
efficiently verify the signature in interest Payload fields? 
Secondly, and perhaps more importantly, if a router is 
able to obtain the key(s) necessary to verify this signa¬ 
ture, how can the router be sure that such key(s) can 
be trusted? 

To address these problems we propose a mutual trust 
framework for authorized disclosure. Ghali et al. 
first studied the problem of trust in NDN, and ICNs in 
general, as a means of preventing content poisoning at¬ 
tacks [h^. Even if routers can verify content signatures 
before relying from their cache, it does not mean that 
said content is actually authentic. Ghali et al. observed 
that this verification process requires insight about trust 
in public keys (used in verification) that is only known 
to applications. Gonsequently, this requires that all in¬ 
terests must either supply (1) the hash of the public key 
used to verify the signature, or (2) the hash of the re¬ 
quested content. In effect, the interest reflects the trust 
context of the issuing consumer in a form enforceable 
at the network layer. This framework can be viewed 
as one-way trust of content by routers. We extend this 
framework to allow producers to distribute information 
about authorized consumers, which can also be enforce¬ 
able at the network layer. This allows routers to make 
trust decisions about individual interests. 

Recall that in order for routers to verify which inter¬ 
ests are authorized to access cached content protected 
under IBAG, the signature in Payload must be verified. 
To achieve this, producers should include the appropri¬ 
ate verification key with each IBAG-protected content 
object. To better understand this, assume the following 
scenario. Gonsumer Cr S Gj, for G^ C U(A), requests 
content with name N by issuing an interest with ob¬ 
fuscated name N', andlDci, r, t and a in Payload as 
described in Section |6.1| Assume that the matching 
content is not cached anywhere in the network. Once 
this interest reaches the producer P, the latter verifies 
cr and replies with the content that also includes the 
verifying key Fd I^o^ter R will then cache pk^. 
along with the content itself. Once another interest for 
N' is received, R uses the cached pk^. to verify a and 
returns the corresponding cached content object. 

We formalize this in the following policy, denoted as 
the Authorized Gontent-Key Binding (AGKB) rule: 


^^The content object signature must also be computed over 
pfcg. to bind it to the message. 
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Algorithm 1 InterestGeneration 

1: INPUT: routable.prefix, N, pk^., sk^., k 
2: IDg- ^ H(fcG,) 

3l N' /routable_prefix//(feG-, SufFix(A^, routable_prefix)) 

4: r- 4^ {0, 1}" 

5l t ■<— CurrentTime() 

6: (7-^-Sign^fcs (7V'||IDGj|r||i) 

7'. Payload := (ID(C^, r, t, (t) 

8: return /[AT^] , Payload) 


Algorithm 2 ContentObjectGeneration 

1: INPUT: /[A^^] (routable.prefix, A^^, Payload) 
2: (IDg^ , r, t, cr) Payload 

3'. pkQ, ■<— LoopupVerificationKeyForlD(IDG-) 

4: if Verify^fc, (cr) then 

5; kQ, <— LookupDecryptionKeyForlD(IDG ) 

6l N -i— Dec{kQ, , Suffix(N', routable.prefix)) 

7: data RetrieveContent(A^) 

8: return CO[N'] (A^^, data, ) 

9: else 

10: Drop /[AT'] 

11: end if 


ACKB: Cached content protected under IBAC must 
reflect the verification key associated with the autho¬ 
rization policy. 

The protocol for IBAC-protected content retrieval re¬ 
lies on this rule. Algorithms and outline the in¬ 
terest and content object generation procedures. Note 
that the function Suffix(A, routable.prefix) returns all 
name components of N except the ones included in 
routable_prefixj^ Also, the router verification procedure 
is outlined in Algorithm If this procedure returns 
Pass, then the content object found in the cache is for¬ 
warded downstream to the associated interface. Note 
that Algorithms 0i, and 14 use obfuscation key fee. 
and signing key pairs (pfcg,,^Q.). For completeness, a 
complete sequence diagram showing multiple interest- 
content exchanges is shown in Figure[2 Both consumers 
belong to the same access group, i.e., Cri,Cr 2 G Gi. 

In Appendix]^ we show that this mutual trust frame¬ 
work for authorized disclosure enables IBAC with stronger 
security guarantees in the presence of replay attacks. 


Algorithm 3 RouterAuthorizationCheck 
1: INPUT; /[AT'], cached CO[Af']. B 

2: (IDg^ , r, f, ct) Payload 

3: {N''-,pk^^):=COlN'] 

4: if B[N^] contains r then 
5: Drop I[N']- return Fail 

6: else 

7: if Timestamp t is invalid then 

8: Drop /[N^]; return Fail 

9: else 

10: if Verify^,,^ (cr) then 

11: B[iV'] := B[Ai'] U r 

12: return Pass 

13: else 

14: Drop /[Ai']; return Fail 

15: end if 

16: end if 

l7: end if 


the exact same name regardless of access control groups 
permitted access. This can be achieved using the hash- 
based name obfuscation function described in Section[5]2l 
However, cached content needs to contain every autho¬ 
rization signature verification key that could be used 
to access said content. In other words, producers need 
to provide all possible public keys that can be used to 
access the content under IBAC protection. Consider 
the following scenario: a content object CO\N] is ac¬ 
cessible by two access groups Gi and Gj. In this case, 
the producer needs to provide both pk^. and pk^, with 
CO[N'], i.e., 

CO[N'] := (A',data,pA:a.,pfca4 

Whenever a router R caching CO\N'] receives an in¬ 
terest issued by a consumer in any of the authorized 
access groups, R uses the group identity included in 
the Payload field to determine cr’s verification key. 

Note that content object sizes might increase signifi¬ 
cantly depending on how many groups are allowed ac¬ 
cess. We do not discuss this issue further, since the 
trade-off between having multiple cached versions of the 
same content and having longer content objects carry¬ 
ing all verification keys is ultimately the application’s 
decision. 

6.4 IBAC Variations 


6.3 Serving Content to Multiple Access Groups 

One problem with encryption-based name obfusca¬ 
tion occurs when a content object with name N is ac¬ 
cessible by different groups. According to Algorithms 
and [4 the obfuscated name N' contains a suffix en¬ 
crypted with keys associated with each access group. 
Therefore, a single content object might have several 
names depending on the number of groups authorized 
to access it. Since routers employs exact matching for 
cache lookupp4 several copies of the same content could 
possibly be cached. 

To solve this problem, content objects should have 

'^^For instance, Suffix(/edu/uci/ics/home .html, /edu/uci/) 
would return ics/home.html. 

^®In CCN, not in NDN. 


We do not claim that any of the IBAC variations 
discussed above is superior to another. Each has its 
own strengths and weaknesses. However, to help guide 
the decision about which variation to use, we make the 
following claims based on the application needs and as¬ 
sumptions. Note that some claims provide privacy as 
well as access control. 

1. If replay attacks are not a concern, then consumers 
only need to use a name obfuscation function and 
include their group identity in the Payload. 

2. If replay attacks are plausible and name privacy 
is a concern, then name obfuscation must be used 
and authorization information, as described in Sec¬ 
tion 6.1 must be included in interest Payload fields. 

3. If replay attacks are plausible but name privacy is 
not a concern, then only authorization information 
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Figure 1: Consumer and producer exchanges for 
IB AC-protected content. 


is sufRcient. 

Claim might seem counterintuitive with the idea of 
IBAC. Recall, however, that router authorization checks 
prevent unauthorized consumers from retrieving cached 
content under IBAC protection. Even if content name 
is not obfuscated, Adv cannot forge Payload autho¬ 
rization information, and therefore cannot violate IBAC 
protection guarantees. 

6.5 Revocation 

Generally speaking, revocation is a challenge in all 
access control schemes involving secrets shared among 
group members. Recall that all consumers belonging to 
the same access control group in IBAC share the same 
obfuscation keys. If one of them leaves the grouj^ the 
producer will have to create a new key and distribute 
it to all remaining authorized consumers. We will not 
discuss this issue further since we believe it is not part 
of the core access control protocol. 

Moreover, in-network caching can cause IBAC con¬ 
tent to be accessed by revoked consumers. Assume con¬ 
tent CO[N] is under access control and has a cached 
version in router R. Assume consumer Cr, connected 
(directly or indirectly) to R, is authorized to access 
CO[N]. However, while CO[N] is cached, Cr’s access is 
revoked. At the same time, the latter sends an interest 
requesting CO[N]. In this case, R will grant access and 

^^For instance, consumers not renewing their subscription for 
a certain service. 


reply with CO[N] from its cache. This is due to the 
fact that the cached version of CO[N] is not updated 
with the correct authorization information (i.e., verifi¬ 
cation key(s)). However, this can be solved by setting 
the ExpiryTime field of CO[N] to a value that reflects 

consumer revocation frequency. _ 

Online revocation protocols, such as OCSP 19 , would 
induce extra communication between R and which 
nearly defeats the purpose of the cache entirely. In this 
case, R would be better suited forwarding the interest 
upstream to P. Another option for the producer would 
be to distribute certificate revocation lists (CRLs) [dj 
with every fresh content. This, however, introduces fur¬ 
ther issues for routers and consumers. Firstly, routers 
would need to store CRLs and keep them updated fre¬ 
quently. Secondly, authorized consumers would need 
their own public and private key pair to compute a. 
Finally, routers would need to perform additional veri¬ 
fications against the CLR. Overall, this approach suffers 
from increased storage, consumer management, compu¬ 
tation, and bandwidth complexity. 


7. ANALYSIS AND EVALUATION 

In this section, we analyze the overhead induced by 
each variation of the proposed IBAC scheme. 

7.1 Computational Overhead 

We first focus on the computational overhead for routers 
and producers. This overhead is captured in terms of 
cryptographic and data structure operations, e.g., sig¬ 
nature verification and hash table lookup costs. Ta¬ 
ble [2] summarizes these results. To further understand 
the computational overhead, we compare two cases: (1) 
when routers perform authorization checks, and (2) when 

they do not. Let To?;er/iearf ~ '^check T '^veri fy P'^update be 

the overhead induced by the authorization check when 
routers receive interests, where Tcheck is the time re¬ 
quired to check for nonce duplication and timestamp 
staleness, T^erify is the time to verify the Payload sig¬ 
nature, and Tupdate is the time to update the nonce 
data collection. Since cache lookup and interest for¬ 
warding are performed regardless of whether or not 
routers perform authorization checks, we omit them 
from this equation. Similarly, Tcheck and Tupdate are 
negligible when compared to the cost of signature veri¬ 
fication Tuerify', thus, they are also excluded. 

A router incurs a computational cost of Toverhead for 
every received interest requesting content under IBAC 
protection. Therefore, we quantify Toverhead by mea¬ 
suring the time it takes to perform a single signature 
verification. We also experiment with batch verifica¬ 
tion techniques to better amortize the cost of signa¬ 
ture verification across series of interests. While this 
naturally increases content retrieval latency since sig¬ 
natures are accumulated in case of batch verification, it 
reduces router computational overhead. Table shows 
the amount of improvement using a variety of signature 
verification algorithms. Note that, when modeling in¬ 
terest arrival rates using a Poisson distribution, both 
individual and batch signature verification incur nearly 

























Table 2: Overview of per-interest IBAC-induced computational overhead for routers and producers. 


IBAC Variation 

IBAC-induced Computation Overhead 

Routers 

Producers 

Name Obfuscation 

Encryption 

None 

One decryption 

Hash 

None 

One hash table lookup 

Interest Signatures 

Encryption 

One signature verification, one nonce 
and timestamp verification 

One decryption, one signature verifica¬ 
tion, Two hash table lookups (decryp¬ 
tion key and signing key resolution) 

Hash 

One signature verification, one nonce 
and timestamp verification, one hash 
table lookup (signing key resolution) 

One signature verification, three hash 

table lookups (decryption key, signing 
key and name resolution) 


Table 3: Individual and batch ElGamal signa- 
ture verification times. 


Key 

Size 

Batch 

Size 

Sig. 

Size 

Indiv. 

Time 

Batch 

Time 

Improved 

1024b 

10 

512KB 

0.599s 

0.322s 

46% 

1024b 

10 

SMB 

0.888s 

0.615s 

30% 

1024b 

50 

512KB 

2.918s 

1.579s 

46% 

1024b 

50 

SMB 

4.315s 

2.991s 

30% 

2048b 

10 

512KB 

4.065s 

2.207s 

46% 

2048b 

10 

SMB 

4.104s 

2.269s 

45% 

2048b 

50 

512KB 

20.081s 

11.029s 

45% 

2048b 

50 

SMB 

21.301s 

12.536s 

41% 

3072b 

10 

512KB 

12.406s 

6.789s 

45% 

3072b 

10 

SMB 

12.804s 

7.122s 

44% 

3072b 

50 

512KB 

60.174s 

32.877s 

45% 

3072b 

50 

SMB 

64.347s 

35.601s 

45% 


the same overhead in certain conditions, as we will show 
below. 

Denial of service (DoS) is an obvious concern if routers 
perform authorization checks. Let A be the rate of 
arrival interests for IBAC-protected content cached in 
router ii, and let /r be the service rate for interests, 
i.e., the rate at which interests are processed (parsed, 
verified, etc.). If /r < A, then the router will be over en¬ 
cumbered with interests to process . We envision that 
in legitimate scenarios without m^rcious entities gen¬ 
erating interests with fake authorization information, 
only a small percentage 6 of arrival interests will be 
requesting content under IBAC protection. To assess 
how susceptible routers are to DoS attacks induced by 
IBAC authorization checks, we empirically analyze the 
effect of 6 on the interest service rate of a router. These 
service rates, which use different signature verihcation 
techniques - individual and batch - denoted and 
respectively, are shown in Figure 

We assume that interests arrive at a base rate of 
Ai = 40 1^; larger values for A are provided to see 
at which point fj, < X due to authorization checks. By 
the exponential property of the Poisson process, ^ is 
calculated as follows: 

1-d 6 

M —-1-7- 

'^process '^process \ '^verify 

where Tprocess represents interest processing time not in¬ 
cluding signature verificatiorj^ and Tyerify is the time 

Tprocess = 1 /mu for interests not requesting IBAC- 



Figure 2: Interest service rates for various per¬ 
centages of IBAC-protected interests. 

required to perform individual or batch signature ver¬ 
ihcation. In our experiment, we assume a constant 
Tprocess = 0.005s and only vary Tyerify To do so, we 
assume a key size of 1024b, batch size of 10, and signa¬ 
ture size of 512KB. According to Table[^ this results in 
Tverify = 0.599s and Tverify = 0.322s for individual and 
batch verihcation, respectively. Our experiments show 
that the decay of p. as a function of 6 is almost iden¬ 
tical for both batch and verihcation techniques. This 
is due to the fact that only a small fraction of inter¬ 
ests are affected by the verihcation step. Furthermore, 
our results show that /r > A is true, i.e., the router ser¬ 
vicing process is stable for reasonable interest arrival 
rates. Our experiments show that /i < A when A = 160 
and S > 0.2. Moreover, when a Poisson process is as¬ 
sumed, both individual and batch signature verihcation 
perform similarly for small values of 6. However, batch 
signature verihcation prove to be advantageous in larger 
S values. For instance, for S = 0.2, using batch verih¬ 
cation provides less than 1% service rate improvement, 
where it provides 3% and 46% for S values equal to 0.8 
and 1, respectively. 

7.2 Storage Overhead 

Storage overhead varies from producer to router. If 
protected content. 
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hash-based name obfuscation is used, producers incur 
the cost of maintaining a hash table to map obfuscated 
names to their original values. However, if content 
name contains variable name components, e.g., query 
string-like values in URIs, the hash table size can grow 
significantly since it has to contain all possible varia¬ 
tions. Moreover, producers must bear the storage cost 
of IB AC access group keys if encryption-based obfusca¬ 
tion functions are used. Similarly, routers must bear the 
cost of storing variable-length tuples of key identities 
IDiq. and the actual verification keys pk^., along with 
a theoretically unbounded collection of nonces for each 
IB AC-protected content. This finite amount of storage 
can be abused to mount DoS attacks on routers. 

7.3 Bandwidth Overhead 

In terms of bandwidth overhead, each interest and 
content object is expanded to include additional au¬ 
thorization information, e.g., interest payloads with au¬ 
thorization information and content objects with au¬ 
thorization keys. Interests without authorization pay- 
loads will only increase (or decrease) by the expansion 
factor of the obfuscated name. If authorization pay- 
loads are included, then interest messages will grow by 
|r| -I- \t\ + \a\ + |IDg|, where |r| = k. Content object 
CO[N] grows with length Ip^g I’ where L is the 
number of access groups allowed to access CO[N] and 
I is the public key size associated with group Gi. 

8. CONCLUSION 

We studied the problem of access control in ICNs. 
We proposed an Interest-Based Access Control (IBAC) 
scheme that supports hash- and encryption-based name 
obfuscation. We addressed the problem of replay at¬ 
tacks by formulating a mutual trust framework between 
producers and consumers - enforced in the network- 
layer - that enables routers to perform authorization 
checks before satisfying interests from cache. We as¬ 
sessed the computational, storage, and bandwidth over¬ 
head induced by each variant of the proposed IBAC 
scheme. Ultimately, we believe that our work brings 
ICNs one step closer to fulfilling their promise of a more 
secure networking paradigm. 
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APPENDIX 

A. PROOFS OF SECURITY 

In this section, we prove the security properties of 
IBAC with and without authorized disclosure with re¬ 
spect to the adversarial model described in Section]^ 
In the following, let N be the name of a content ob¬ 
ject under IBAC protection and generated by P. Also, 
let adversary Adv = ("PAdv \ {-P},CAdv \ U(A),7^Adv \ 
Path(Cr,P)), where Cr G U(A). 

Theorem 1. The IBAC scheme without authorized 
disclosure is secure, but subject to replay attacks, against 
Adv if an indistinguishably-secure (IND-secure) deter¬ 
ministic encryption algorithm is used for name obfus¬ 
cation. 


Note: IND security is typically identical to CPA secu¬ 
rity in the public-key setting since the adversary is as¬ 
sumed to have access to the public key 14 . In this case, 
neither the encryption nor decryption key is known to 
Adv. 


Proof. Let n = (Gen, Enc, Dec) be an IND-secure 
(deterministic) encryption scheme consisting of three 
probabilistic polynomial time algorithms Gen, Enc, and 
Dec for key generation, encryption, and decryption, re¬ 
spectively. Let ke and kd be the encryption and de¬ 
cryption keys produced by Gen. For any interest name 
N, it holds that Dec(fcd, Enc(fce, A)) = N. Let Adv 
be any probabilistic polynomial adversary. The defi¬ 
nition of the eavesdropping indistinguishability experi¬ 
ment, adapted for plaintext interest messages, denoted 
Exp^j^ jj, is as follows: 

1. Adv is given input 1” and outputs a pair of interest 
names Nq and Ni , and fee and kd are computed by 
running Gen(l”). 

2. A single bit b G- {0,1} is chosen uniformly at ran¬ 
dom. The challenger computes the ciphertext c •<— 
Enc(A:e, Nt), which is given to Adv. 

3. Adv outputs a single bit 6'. 

4. The output of the experiment is said to be 1 if 
b' = b and 0 otherwise. 

Let ExpAdv. ]d(«:, b) be the same experiment run but where 


bit b is given as an input value. By the definition of 
IND-security, it follows that 

|Pi'[ExpAd^_n(«.l) = 1] -Pi'[ExpXdv.n('«>0) = 1]| < e(/c), 

for some negligible function e. Recall that Guess is the 
event that Adv correctly guesses the obfuscated version 
a content name. The probability of Adv decrypting a 
message is at least Pr[Guess]. Therefore, the event when 
Adv successfully guesses the obfuscated version of the 
name, is when Adv outputs 6' = 1 when 6=1 and 
6' = 0 when 6 = 0. Thus, 

Pr[Guess] = | Pr[Exp;^^^_n(«> U = 1] 
-Pr[ExpXdv.n(K:0) = l]l 

< e{K) 

This concludes the proof. □ 

Theorem 2. The IBAC scheme with authorized dis¬ 
closure is secure, in presence of replay attacks, against 
Adv if an indistinguishably-secure (IND-secure) deter¬ 
ministic encryption algorithm is used with an existen¬ 
tially unforgeable signature scheme. 

Proof. In Theorem we proved that Pr[Guess] < 
e(K). It is easy to see that the additional Payload infor¬ 
mation - the random nonce, timestamp, and signature 
- are all distinct for each interest. Therefore, including 
this information leaks no information that improves the 
adversaries advantage or improves Pr[Guess]. 

We now assess Pr[Bypass]. Recall that this event oc¬ 
curs when Adv bypasses the authorization check at a 
router to recover content from a cache. Without knowl¬ 
edge of sk^, , this only occurs if Adv is able to forge the 
Payload signature. By definition of the existentially 
unforgeable signature scheme, Adv is not able to gen¬ 
erate an input set (iV', IDg., f, t) (A', IDg^, r, t) such 
that Verifyp;.g (d) occurs with non-negligible probabil¬ 
ity. Thus, Pr[Bypass] < e(K). Finally, since the sum 
of two negligible probabilities is also negligible, then 
Pr[Guess -I- Bypass] < €{k) . □ 
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